Capítulo 4
=4.1. Sobre $LFS= A través de este libro, la variable $LFS será usada. Es fundamental que esa variable este definida. Debe de ser configurada para apuntar a la partición LFS. Comprueba que es correcto con: echo $LFS Asegúrate que el resultado es la partición LFS si el valor por defecto es /mnt/lfs, si no para cambiarla debemos ejecutar el siguiente comando cambiándolo por el directorio adecuado, ej: export LFS=/mnt/lfs Tener esto definido permite que comandos como mkdir $LFS/tools puedan ser ejecutados literalmente. El shell automáticamente reemplazará “$LFS” por “/mnt/lfs” (o cualquier valor elegido) al procesarlo. No te olvides de comprobar si $LFS está configurado cada vez que entres o salgas (esto incluye le comando su). =4.2. Creando el directorio $LFS/tools= Todos los programas compilados en el capitulo 5 serán instalados en $LFS/tools para mantenerlos separados de los compilados en el Capitulo 6. Estos programas son temporales y no formarán parte del sistema LFS final. Manteniéndolos en un directorio separado permite su facil eliminación .También evita que acaben en los directorios de trabajo del host (fácil de hacer por accidente Capítulo 5). Crea el directorio requerido mediante : mkdir -v $LFS/tools El siguiente paso es crear un symlink a /tools en el host. Esto apuntara al directorio recién creado. Corre este comando como root: ln -sv $LFS/tools / Ten en cuenta que El siguiente comando es correcto. El comando ln tiene unas pocas variaciones sintácticas, así que asegúrate de comprobar''' info coreutils ln''' y ln(1) antes de reportar ningún error. El symlink permite que todo lo compilado apunte a /tools, significando que el compilador, enlazador y ensamblador funcionaran en el capitulo 5 (cuando todavía usamos herramientas del host) y en el capítulo 6 (cuando estamos en una jaula chroot en el LFS). =4.3. Añadiendo el usuario LFS= Logueados como el usuario root, con un solo fallo podremos dañar o destruir nuestro sistema. Por lo que es recomendable construir los paquetes como usuario sin privilegios. Puedes usar tu propio nombre, pero para mantener un sistema de instalación limpio es mejor crear un nuevo usuario llamado lfs, miembro de un grupo llamado tambien lfs y úsalo durante la instalacion. Como root, ejecuta los siguientes comandos . groupadd lfs useradd -s /bin/bash -g lfs -m -k /dev/null lfs El significado de las opciones de línea de comandos: ;-s /bin/bash :convierte a bash el shell por defecto para lfs . ;-g lfs :Añade lfs al grupo lfs. ;-m :Crea un directorio home para lfs. ;-k /dev/null :Evita que se copien archivos a /etc/skel cambiando la entrada a un dispositivo virtual nulo. ;lfs :El nombre del grupo y el usuario. Para loguearte como lfs, asígnale una contraseña passwd lfs Garantiza a lfs acceso completo a $LFS/tools convirtiendolo en el propietario: chown -v lfs $LFS/tools Si se creó un directorio de trabajo diferente, le da la propiedad del directoria a lfs chown -v lfs $LFS/sources Ahora, logueate con lfs su - lfs =4.4. Configuración del Entorno de Trabajo= Configura un buen entorno de trabajo creando nuevos archivos del shell bash. Mientras estes logueado como lfs ingresa el siguiende comando para crear el .bash_profile: cat > ~/.bash_profile << "EOF" exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash EOF Mientras hagas login como lfs, el shell normalmente es un login shell que lee /etc/profile del host (que probablemente contenga configuración y variables del entorno) y el .bash_profile. el comando exec env -i.../bin/bash en .bash_profile file sobreescribe el entorno por uno completamente nuevo, excepto por las variables HOME, TERM, y variables PS1. Esto garantiza que ninguna variable potencialmente peligrosa del host llegue a nuesto LFS. El nuevo shell es un non-login shell, que no lee el /etc/profile o los archivos .bash_profile , pero lee el en su lugar .bashrc Crea el .bashrc ahora: cat > ~/.bashrc << "EOF" set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL LFS_TGT PATH EOF El comando set +h desactiva la funcion hash de bash. Hashing es normalmente una caracteristica util bash usa una tabla de hash para recordar el directorio completo del ejecutable y evitar buscar repetidas veces el ejecutable. De todos modos las herramientas deben ser usadas nada más se instalen. Apagando la funcion de hashing, que bash buscará el PATH que vaya a ser ejecutado. De ese modo el shell encontrará las herramientas en $LFS/tools tan pronto como esten disponibles . Configurar la umask a 022 asegura que los directorios y archivos solo son modificables por el dueño , pero leeibles y ejecutables por los demas . La variable LFS debe ser configurada antes de este punto. La variable LC_ALL controla la localización de ciertos programas , haciendo a sus mensajes seguir las convenciones especificadas en sus paises. SI el host usa una version de glibc anterior a 2.2.4, tener LC_ALL configurado a algo distinto a “POSIX” o “C” (en este capitulo) Puede causar problemas al salir del chroot . Configurar LC_ALL a “POSIX” o “C” (Son equivalentes ) Asegura que todo funcionara como debe en el chroot. The LFS_TGT variable sets a non-default, but compatible machine description for use when building our cross compiler and linker and when cross compiling our temporary toolchain. More information is contained in Section 5.2, “Toolchain Technical Notes”. Poniendo /tools/bin antes que el DIRECTORIO estandar todos los programas instalados en el Chapter 5 son cogidos por el shell . Esto , combinado con desactivar el hashing, Limita el riesgo de que los programas usados en el capitulo 5 sean los mismos que los viejos de host Para tener el entorno plemante funcional , hay que crear el perfil bash source ~/.bash_profile =4.5. About SBUs= Mucha gente querra antes de empezar saber cuanto tarda compilar cada paquete. Como LFS puede ser construido de muchas maneras , es imposible proveer tiempos aproximados precisos . El mas grande (Glibc) tardara unos 20 minutos en los sistemas mas rapidos , pero podria tardar hasta tres dias en los mas lentos .En lugar de proveer tiempos de compilacion reales , la SBU (standard build unit) sera usada . La medida SBU funciona aso . El primer paquete compilado es binutils , en el Chapter 5. El tiempo que tarde en ser compilado sera la SBU .Todos los demas tiempos seran medidos respecto a esta medida . Por ejemplo , imagina un paquete que tarda 4.5 SBUs en ser compilado . Esto significa que si el tiempo de compilación de binutils fue 10 minutos , este tardara 45 . Afortunadamente , la mayoria de los paquetes tardan menos de 1 SBU En general , las SBU no son muy precisas porque dependen de muchos factores : version de gcc , optimizaciones , arquitectura ... Note En muchos sistema actuales , estan disponibles varios procesadores , nucleos o hilos , por ejemplo un Core2Duo puede manejar dos procesos a la vez , para compilar con esta carateristica ; export MAKEFLAGS='-j 2' o compilar con : make -j2 Cuando varios procesadores son usados , la SBU se desvian mas , tambien es mas dificil leer el log de error . Si tienes problemas al compilar , intenta compilarlo con un solo nucleo y lee el log de error =4.6. About the Test Suites= Muchos paquetes proveen un banco de pruebas (test suite) . Ejecutarlo es una buena idea por que funciona como un "test de salud" para el paquete , indicanto que todo a sido compilado correctamente. Esto no garantiza que este libre de bugs Algunos bancos de pruebas son mas importantes que otros . Por ejemplo , los de los paquetes—GCC, Binutils, and Glibc—Son de vital importancia por su rol de nucleo en el sistema . Los de GCC y Glibc pueden tardar mucho tiempo en finalizarse , pero estan altamente recomendados Note La experiencia ha enseñado que hay poco que ganar corriendolos en el capitulo Chapter 5. Puede que no halla manera de escapar de la influencia del host en los test de ese capitulo .Causando fallos inexplicables. Como las herramientas usadas en el capitulo Chapter 5 son temporales , no es recomendable ejecutar los bancos de pruebas en el capitulo Chapter 5 para la mayoria . Las instrucciones son proveidas para los desarrolladores , pero son estrictamente opcionales .Un problema comun en los de GCC y Binutils es que corren en pseudo-terminals (PTYs). Esto puede resultar en un alto numero de fallos , aunque existen muchos motivos , es probable que se deva a que el host no tiene /dev/pts configurado correctamente Este problema es explicado en http://www.linuxfromscratch.org/lfs/faq.html#no-ptys. A veces las pruebas fallan , pero los desarrolladores estan al corriente y las marcan como no-criticos . Consulta el log en : http://www.linuxfromscratch.org/lfs/build-logs/7.4/ Para verificar si es o no esperado ese fallo.